Functional verification of a chip design has become more and more difficult with increasingly complex electronic designs. Attaining sufficient coverage of the design space with simulation is an ever-increasing problem. Traditional, signal-level test benches are difficult to create, maintain, and reuse. Standard mechanical coverage metrics such as line coverage and statement coverage help determine what portions of a design have not been tested at all, but they do not tell how thorough or effective testing has been for the portions that have been tested. Various techniques have been developed to improve verification coverage and provide more visibility into verification quality.
One approach is transaction-based verification, which focuses on higher-level behavior called “transactions” rather than signals as the basis for stimulation, observation, and coverage analysis. A transaction is characterized by its start and end times, the kind of operation involved, and other attributes associated with the transaction. At the abstract level, a transaction is a single transfer of high-level data or control between a Test-Bench and a design under verification (DUV), which consists of two design blocks. At the hardware level, a transaction is essentially a typically multi-cycle operation involving control and possibly data signals.
Transaction verification modules (TVMs) provide a mapping between these two views, allowing abstract transactions to be injected into the DUV, or observed as they occur within the DUV. A Master TVM and a slave TVM mediate the transfer of data between the Test-Bench and the DUV, by translating between the abstract and signal-level representations of a given transaction. The Master TVM and the Slave TVM contain transaction monitors to detect in the DUV the signal-level activity indicating the occurrence of a given signal level transaction and translating that activity to the corresponding abstract transaction, a concise representation of which can then be recorded in the simulation database. The Test-Bench monitors transactions crossing the boundary between the device and the test environment. Similarly, transactions occurring on internal buses can be detected by monitors. Transaction analysis allows verification to focus on relevant high-level behavior without getting lost in the details.
Typically, transaction-based verification and transaction-based functional coverage analysis have been driven largely by the test environment and used by verification engineers, who prefer to adopt a “black-box view” of the design in order to maximize reuse of the test environment. Transaction-based coverage analysis in this context therefore tends to focus on system-level interfaces and scenarios, and therefore on transactions between the test-bench and the DUV, and between major components of the DUV.
Another approach to functional verification of electronic designs is called assertion-based verification. Assertion-based verification is based upon an Assertion Language, which allows designers to embed information into their designs to facilitate verification. The Assertion Language allows designers to capture assumptions, specifications, and operations of a design, so that internal errors can be caught more quickly, assumptions can be checked easily, and functional blocks can be verified more easily when inserted into another design.
Assertions are built up from Boolean expressions, or conditions, which are evaluated at certain times during the execution of the design. For example, one of the simplest forms is the assertion “always C”, where C is a condition; the assertion “always C” says that C must be true in each clock cycle. More complex, multi-cycle behavior can be expressed with sequences, which consist of a list of conditions that may or must be true in successive cycles, such as c1, c2, c3, . . . , cn, where c1 through cn are conditions that may or must be true in cycles 1 through n.
Before a whole design can be verified, it is appropriate to verify that the major blocks function correctly with respect to their interfaces. Verifying a block often involves the block's designer, who necessarily has a “white-box” view of the design. Assertion-based verification can be used to capture and verify the designer's knowledge of the internal details of the block, and the assumptions made in its architecture and implementation.
Transaction-based verification is primarily used by verification engineers who are responsible for developing test environments for system-level verification of large designs. Assertion-based verification is primarily used by design engineers who are responsible for designing digital blocks and systems. Currently, the two tools are used independent of each other without benefiting from one another. It would be advantageous to have an improved method for functional verification of electronic designs by combining transaction-based verification and assertion-based verification using assertion-based transaction recording.